![[レポート] ビッグデータ 101 ～ AWS で始めるビッグデータパイプラインの設計と実装～ #AWSSummit](https://devio2023-media.developers.io/wp-content/uploads/2016/06/aws-summit-tokyo-2016.png)
[レポート] ビッグデータ 101 ～ AWS で始めるビッグデータパイプラインの設計と実装～ #AWSSummit
当エントリは、先週開催された『AWS Summit Tokyo 2016』、3日目のセッション『ビッグデータ 101 ～ AWS で始めるビッグデータパイプラインの設計と実装～』のレポートです。
当日はプレス参戦していた為、写真を交えてセッション参加レポートをお送りしたいと思います。当セッション登壇者はアマゾンウェブサービスジャパン ソリューションアーキテクト 内海 英一郎氏です。
目次
昨今、多くのお客様がAWS上でビッグデータを活用。セッション内でも以下3つの事例について紹介がなされました。以下に関連動画/スライド資料を展開します。
AdRoll：50ミリ秒以下のレスポンスで1日600億のインプレッションを処理
FINRA：5ペタバイト超のストレージで1日最大750億のイベントを処理・分析
Hearst：250以上のウェブサイトから1日100GBのクリックストリームを収集
これらを踏まえた上で、内海氏は『ビッグデータのサービスも増え、これらのサービスを上手く組み合わせて活用して行くのが現在では非常に難しくなって来ています。当セッションではこの複雑さについて皆さんと考え、どの様な選び方、使い方をして行けば良いのかについて見てて行きたいと思います』とコメントし、解説を始めました。
アーキテクチャ全体のモデリング
まずは『アーキテクチャ全体のモデリング』から。この部分については『最も抽象的な概念から始めましょう』とし、データの断片を、価値を持った情報に変える為には何をどうすれば良いのか？という視点を持って必要な要素を見極めて行く術について解説。これを実現するにはどうすればよいか？発生した場所から目的地へ移動させる為に何をすれば良いか？を見て行く事で、必要な処理が整理されて行く、というものです。
また、この『データの断片』を『価値を持った情報』に変えて行くに当たって必要なフェーズをそれぞれ『収集』『前処理』『保存』『後処理』『提供』の5つのフェーズに分割。更にはそれぞれのフェーズで用途や目的、処理の内容に応じた細分化が内海氏の解説により整理されて行きました。以下はそれらの内容を表にまとめたものです。
| フェーズ | フェーズ毎の処理内容 | ||
|---|---|---|---|
| 名前 | 説明 | 名前 | 説明 |
| 収集 | データソースへの インタフェースを提供 |
ファイル | ペイロードサイズが大きい、データの発生頻度が低い。 |
| ストリーム | ペイロードサイズが小さい。データの発生頻度が高い。 | ||
| 前処理 | 収集したデータを 保存用に変換・登録 |
バッチ | 収集データをまとめて処理。 時間辺りの処理能力、スループット重視。 |
| リアルタイム | データを収集した段階で処理、レイテンシー処理。 どれくらい短い時間で処理出来るか、が指標。 |
||
| 保存 | 繰り返し保存される データを蓄積・保持 |
RDB | ハードスキーマ、アクセスパターンの制約無し。 いわゆるシーケンシャル、ランダムアクセスが可能。 スケーラビリティに制限あり。 |
| NoSQL | ソフトスキーマ。key-value。アクセスパターンの制約無し。 | ||
| サーチエンジン | 目的特化。ソフトスキーマ。全文検索、スコアリング等。 | ||
| DWH | ハードスキーマ、大容量データの複雑な問い合わせに最適化。 | ||
| ストリーム ストレージ |
スキーマフリー。データの到着順に一定期間のウインドウを保持。 1週間、1日など。 今から1時間前のデータを検索したい、の今(が変わる)。 |
||
| データレイク | スキーマフリー、後から自由に処理。柔軟性は高い。 | ||
| 後処理 | 保存したデータを 提供用に変換・展開 |
機械学習 | 保存データへのアルゴリズムを適用。 予想が主用途。 |
| クエリ処理 | クエリ。保存データへの抽出等 | ||
| 提供 | 情報を取れるような インタフェースを提供 |
可視化 | 人間向けのインタフェース。 スプレッドシートやグラフ等 |
| API | コンピュータ向けのインタフェース。HTTP経由のJSONやXML | ||
AWSサービスを選択する際の着眼点
サービス選びの指針については『やりたい事に最適化されたものを選ぶ』のが第一であると内海氏はコメント。その上で『Right Tools for the Job(機能的特性と性能的特性の両面から最適なサービスを見極める)』『Magaged Services First(インフラの運用をAWSに任せてアプリケーションの開発に集中する)』という2つのポイントを強調しました。性能特性については、『何を最適化する為に、何を犠牲にするか。どの面に於いても万能なものを選びたいと思うが、万能であるという事は、逆に言えばどこにも最適化されていないという事。導入段階では見えない部分なので注意する必要があります』とハマりやすい部分についても言及していました。
その上で、どのケースでどのサービスを選ぶべきかについて、先程のフェーズ、処理内容に対応する形で1つ1つ当てはめて行きました。こちらも上記表のカテゴリに倣う形で整理してみたいと思います。
| フェーズ | 処理内容 | 対応サービス |
|---|---|---|
| 収集 | ファイル | ・Amazon S3 ・AWS Import/Export Snowball |
| ストリーム | ・Amazon Kinesis Streams ・Amazon Kinesis Firehose |
|
| 前処理 | バッチ | ・Amazon EMR ・AWS Data Pipeline |
| リアルタイム | ・AWS Lambda ・Amazon EMR |
|
| 保存 | RDB | ・Amazon RDS |
| NoSQL | ・Amazon DynamoDB ・Amazon Elasticsearch Service |
|
| サーチエンジン | ・Amazon CloudSearch ・Amazon Elasticsearch Service |
|
| DWH | ・Amazon Redshift | |
| ストリーム ストレージ |
・Amazon Kinesis Streams (パラメータを変更する事でストレージ的な利用が可能) |
|
| データレイク | ・Amazon S3 | |
| 後処理 | 機械学習 | ・Amazon Machine Learning ・Amazon EMR |
| クエリ処理 | ・Amazon EMR (Hive,presto等を活用) ・Amazon QuickSight (現在プレビュー版、SPICEエンジンを活用) |
|
| 提供 | 可視化 | ・Amazon EMR (Hue,Zeppelin等を活用) ・Amazon Elasticsearch Service (Kibanaを活用) ・Amazon QuickSight |
| API | ・Amazon API Gateway ・AWS Lambda |
典型的なユースケースの実践方法
上記の『テーマ別サービスの選び方』を元に、幾つかのユースケースからどのように適したサービスを選んでいくか、という部分についての実践・解説がなされていきました。サンプルケースは全部で3つ。
ユースケースからキーワードとなる部分を抽出し、
(前述の表に整理した)テーマ別の観点からそれぞれ適しているサービスを選択。サービス毎の使い方も用途に適した内容で解説されており、とても分かり易かったです。この辺りについては資料が公開されるという事なので、公開され次第丁寧に読み込んで理解しておこうと思います。
最後に本セッションのポイントとなった部分を振り返り、締め。とても分かり易い、タメになるセッションをありがとうございました！
まとめ
AWSでは現時点で70を超えるサービスが展開されており、ビッグデータ周りに絞ったとしてもその数は多いです。個人的にも、ビッグデータ周りの(当セッションで紹介されているような)サービス群については若干整理仕切れていなかった部分があったのですが、当セッションを聴講する事でその辺りが非常にクリアになりました。社内のビッグデータ業務を加速させるべく、当セッションで紹介されたサービス群を中心にバリバリ使いこなし、情報発信もして行ければと新たに感じた次第です。
![[レポート]AWSでデータメッシュアーキテクチャを構築する#ANT336 #reinvent](https://devio2023-media.developers.io/wp-content/uploads/2022/11/eyecatch_reinvent2022_session-report.png)
